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i  .0  Research  Objectives 

The  objective  of  this  research  was  to  investigate  the  portability 
of  operating  system  (OS)  software.  True  portability  is  interpreted  as 
the  ability  to  run  a  program  unchanged  on  multiple  heterogeneous  host 
machines.  The  basic  heterogeneity  of  such  host  computers  means  that  any 
OS  must  be  changed  to  accommodate  low-level  architectural  features. 
Therefore,  we  chose  to  study  the  structure  of  an  adaptable  OS  which  can 
execute  on  various  machine,  operating  system,  and  computer  network 
architectures.  This  research  effort  has  produced  the  following  results: 

1.  an  adaptable  core  operating  system  written  in  Concurrent 
Pascal , 

2.  a  network  adaptable  executive  (operating  system)  which 
supports  distributed  programming, 

3.  a  distributed  program  construction  and  control  system,  and 

4.  performance  comparisons  of  high-level  language  based 
operating  systems  under  structural  variations. 

During  this  study,  we  produced  three  published  papers  (and  one  still  in 

preparation),  eleven  technical  reports,  and  30,000  lines  of  Pascal  and 

Concurrent  Pascal  [5.1]  code  which  constitute  a  Network  ADaptable 

Executive  (NADEX)  and  its  program  development  subsystems. 

In  this  document  we  will  describe  our  approach  to  porting  the 
various  layers  of  an  operating  system,  the  basic  services  and  structure 
of  the  NADEX  systems,  and  their  performance.  We  will  also  relate  each 
element  of  the  system  to  our  reports  and  papers  whose  abstracts  appear 
in  Section  4.  In  order  to  distinguish  these  papers  from  other 
references,  the  other  references  are  in  Section  5. 

The  approach  we  have  taken  is  to  study  the  functionality  ar.c 
layering  of  a  distributable  operating  system,  define  the  portability 
properties  of  each  layer,  implement  the  system  ' including  its  program 
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development  subsystems) ,  and  then  test  its  performance.  The  result  is 
NADEX.  It  has  two  layers — a  distributed  programming  environment  and  a 
core  operating  system.  The  core  operating  system  is  ported  relatively 
easily  due  to  its  implementation  in  a  strongly  typed  concurrent 
language — Concurrent  Pascal.  It  provides  a  message-passing  core  on 
which  all  of  the  NADEX  distributed  programming  environment  is 
implemented.  The  portability  of  the  programming  environment  is  based  on 
this  ability  to  pass  messages  between  programs  in  what  we  call  a 
software  configuration. 

These  configurations  are  general  graphs  of  communicating  programs 
(sequential  or  concurrent)  which  can  be  distributed  across  a  computer 
network.  The  NADEX  distributed  programming  environment  is  a  software 
configuration  itself;  and  therefore  it  is  adaptable  to  other 
message-based  core  operating  systems  (UNIX  [5.7],  for  example)  and  is 
distributable  across  a  network.  This  configuration,  in  turn,  supports 
the  creation,  distribution,  initiation,  synchronization,  and  termination 
of  distributable  user  software  configurations. 

NADEX  has  been  implemented  and  is  running  as  a  prototype  on  a 
Perkan-Elmer  (Interaata)  8/32.  It  is  ready  to  be  tested  in  a  network 
environment.  In  addition,  the  feasibility  of  porting  it  to  other  core 
operating  systems  such  as  UNIX,  U CSu  Pascal  system,  and  Perkin-Elmer ' s 
OS-32/MT  has  been  studied.  All  seem  to  be  feasible  under  varying 
degrees  of  effort.  UNIX  seems  to  be  a  willing  host  while  the  latter  twc 
will  involve  mere  effort. 

Me  have  also  tested  the  performance  of  the  NADEX  core  operating 
system  under  various  structural  changes.  Performance  experiments  were 
carried  out  which  isolated  (1)  the  impact  of  a  centralized  buffer  system 
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versus  a  de-centralized  one  as  the  central  element  of  the  NADEX  core  CS, 
(2)  the  impact  of  a  high-level  language  versus  an  assembler  language 
kernel,  and  (3)  the  impact  of  a  multi-level  concurrent  program 
(hierarchical  virtual  Concurrent  Pascal  machine)  kernel. 

In  Section  2,  we  overview  the  layering  of  the  NADEX  systems,  their 
relationship  to  other  core  operating  systems,  and  the  distributed 
programming  tools  which  have  been  developed.  We  also  present  the 
results  of  the  performance  experiments. 
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2.1  Introductory  NAD EX  Concepts 

The  results  of  this  research  are  the  NADEX  core  operating  system, 
the  NADEX  distributed  programming  environment,  and  the  performance  and 
portability  properties  of  each.  This  section  contains  a  discussion  of 
the  function  and  layering  of  tne  NADEX  systems  and  the  impact  on  the 
adaptability  of  this  layering.  This  section  concludes  with  a  discussion 
of  NADEX  performance  measures. 

NADEX  is  a  distributed  programming  environment  and  a  core  operating 
system  whose  objective  is  to  support  nodular  programming.  This  concept 
of  "programming  in  the  small"  which  has  been  so  successful  in  UNIX 
[5.7] — in  the  form  •«  cf  pipelines  of  communicating  sequential 
processes— is  extended  to  support  general  graphs  of  communicating 
programs  under  NADEX.  These  general  graphs  are  called  software 
configurations  and  consist  of  nodes  which  communicate  via  Data  Transfer 
Streams  (DTSs).  These  DTSs  are  full-duplex  in  nature  and,  therefore, 
support  bi-directional  communication  between  any  two  nodes  which  they 
connect.  Nodes  access  DTSs  via  ports.  These  ports  are 
distribution-independent  and,  therefore,  permit  r.ode3  of  a  configuration 
to  be  distributed  across  a  computer  network  without  reprogramming. 

NADEX  supports  three  programmer  views — the  single  node  programming 
view,  the  data  flew  abstraction,  and  the  overall  software  cor.f iguraticr. 
structure.  It  provides  the  compilers  and  PREFIX  for  sequential  and 


concurrent  programs,  the 


iterations 


and  the  cor.f  icuratior. 


descriptor  for  a  distributable  configuration,  respectively ,  for  these 
programmer  views.  It  also  permits  expression  of  these  views  in  a  .ser 


tailored  syotem.  Command  processors,  utility  subsystems  .such  as  fil 


systems),  and  configuration  description  languages  can  be  specified  by 
the  user.  These  systems  can  be  constructed  upon  iJADEX  which  provides 
only  the  essential  elements  of  an  operating  system— interprocess 
communication,  a  representation  for  distributable,  communicating 
processes  (software  configurations),  and  resource  allocation.  It  is  the 
DTS  concept  which  permits  software  configurations  to  be  distributed 
across  a  computer  network  controlled  by  NADEX. 

MAD EX  supports  a  concept  we  call  a  software  configuration — referred 
to  as  merely  a  configuration  throughout  this  document.  A  configuration 
consists  of  a  collection  of  nodes  connected  by  data  transfer  streams 
(DTS's).  Nodes  can  be  user  programs  (both  sequential  and  concurrent 
languages  such  as  Sequential  Pascal  and  Concurrent  Pascal),  file  access 
nodes  (for  accessing  files  within  the  NADEX  file  system),  I/C  device 
access  nodes  (for  accessing  I/O  devices  not  supported  by  the  NADEX  file 
system),  or  external  configurations  such  as  subsystems. 

Nodes  within  the  configuration  are  connected  by  DTS's  which  are 
also  called  connections.  Each  connection  consists  of  two  bi-directional 
components— data  and  parameter.  The  data  component  transfers  data  in 
page-sized  blocks  (a  page  is  512  bytes)  and  interfaces  to  the  user 
program  at  the  page,  logical  record,  or  character  level.  The  parameter 
component  transfers  small  parameter  blocks  typically  used  for  control 
information.  The  data  and  parameter  components  are  totally  independent. 
The  two  directions  of  each  component  are  independent  in  the  sense  that 
each  direction  has  its  own  queue,  but  the  user  protocol  restrictions  are 
defined  in  terms  of  the  bi-directional  components. 

For  purposes  of  these  discussions,  we  will  speak  of  a  node  issuing 


reads  and  writes  to  a  DTS. 


These  should  be  assumed  to  be  read- page 


write-page  requests  for  the  data  component,  and  read-parm  and  write-parm 
requests  for  the  parameter  component.  The  blocking  of  character  and 
logical  record  data  into  pages  is  handled  by  a  PREFIX  of  the  nodes  ana 
will  not  be  discussed  here.  Unless  otherwise  specified,  all  discussions 
apply  equally  to  data  and  parameters,  and  no  distinction  will  be  made. 

There  are  no  structural  restrictions  on  the  graph  formed  by  the 
nodes  and  connections  (DTS's).  In  particular,  it  need  not  be  linear  (as 
in  UNIX  [5.7])  or  hierarchical.  It  need  not  even  be  acyclic  or 
connected.  Nodes  are  not  precluded  from-  having  connections  to 
themselves.  Thus,  the  configuration  is  described  by  a  (labeled) 
undirected  graph.  The  labeling  occurs  where  each  connection  enters  the 
two  (not  necessarily  distinct)  nodes  it  connects. 

The  user  programs  (as  well  as  the  various  system  routines  which 
implement  the  other  nodes)  address  the  connections  emanating  from  each 
node  by  DTS  identifiers  local  to  the  node.  These  local  DTS  identifiers 
are  also  called  port  numbers.  The  meaning  of  the  data  stream  associated 
with  each  port  is  defined  by  the  program.  Port  numbers  are  generally 
assigned  by  the  programmer  starting  with  or.e.  These  port  numbers  are 
the  labels  on  the  configuration  graph. 

The  structure  of  a  configuration  is  defined  by  an  interactive  (PCD) 
construction  program  which  builds  a  file  called  a  Partial  Configuration 
Descriptor  (PCD).  The  PCD  defines  the  structure  of  the  cor.f iguratior. 
and  the  type  (user  program,  file  access,  etc.)  of  each  node.  PCD  files 
can  be  hierarchical  so  that  they  can  be  constructed  in  a  nodular  manner 
as  a  composition  cf  other  PCDs.  When  the  user  requests  that  a 
configuration  oe  run,  via  a  terminal  command  language,  the  PCD  is  used 
along  with  information  from  the  command  to  construct  a  configuration 
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descriptor  (CD).  The  configuration  descriptor  includes  all  of  the 
information  about  the  configuration  including,  for  example,  the  names  of 
the  files  to  be  accessed  by  the  file  access  nodes.  The  configuration 
descriptor  contains  enough  information  for  the  system  to  allocate 
resources  across  the  network.  This  set  of  distributed  programming  tools 
which  are  available  under  N'ADEX  is  illustrated  in  Figure  1  .  In  addition 
to  the  PCD  construction  tools,  the  structure  of  the  PCD  can  be  shewn 
graphically  as  well  as  textuaiiy  as  seen  in  Figure  1 .  Thus,  the  PCD 
Workbench  provides  the  user  with  the  ability  to  specify  general  graphs 
of  programs  in  a  terminal  command  language,  construct  them  in  a 
hierarchical  manner  and  automatically  generate  graphic  and  text  output. 
The  set  of  programs  ar.d  tools  of  Figure  1  are  documented  ir.  repents 
4.2.4  through  4.2.3.  If  the  NADEX  programming  system  is  used  on  a 
single  machine,  the  configuration  is  submitted  to  the  NADEX  core 
operating  system  for  execution. 

The  PCD  Workbench  programs  permit  the  user  to  specify  the  manner  in 
which  the  configuration  is  to  be  distributed  across  a  computer  network. 
Thus,  the  CD  contains  information  about  the  residence  of  data  and 
programs  within  the  network.  Given  this  Network  Configuration 
Descriptor  (NCD),  the  NAD EX  distributed  programming  environment  can 
distribute  the  configuration  across  the  network;  and  it  can  initiate, 
synchronize,  and  terminate  the  individual  parts  of  the  configuration. 

The  manner  in  which  this  is  accomplished  is  illustrated  in  Figure 
2.  The  NCD  is  broken-up  into  the  tarts  (called  local  CDs)  whior.  are  to 


be  run 

on  the  separate 

machines. 

The  are 

sent  to  a  network 

oonf igu 

ration  control  (MCC) 

program  on 

each  machine. 

The  '.ICC  programs 

across 

the  network  thus 

cooperate 

to  synchronize 

the  initiation, 

FIGURE  2 

DISTRIBUTION  OF  SOFTWARE  CONFIGURATIONS  ACROSS  A  COMPUTER  NETWORK 
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execution,  and  termination  of  distributed  configurations.  The  execution 
of  an  LCD  is  carried  out  by  a  local  MADEX  or  other  core  operating.  The 
implementation  of  the  data  exchange  between  nodes  (DTSs)  is  via  a 
network  inter-process  communication  system  called  MIMICS.  More  detail 
on  the  components  of  each  element  of  MADEX  is  presented  in  the  next 
section. 


2.2  Aiiaa.Lab.il ity  M  NAPSX  Layar-s 

Figure  3  contains  an  illustration  of  the  implementation  structure 
of  the  MADEX  distributed  programming  environment  and  its  relationship  to 
the  MADEX  core  operating  system  and  the  UMIX  core  operating  system.  In 
the  remainder  of  this  section,  the  functions  of  the  components  of  this 
system  will  be  discussed.  The  porting  properties  of  MADEX  will  also  be 
discussed  and  these  will  be  illustrated  in  Figure  4. 

The  MADEX  core  operating  system  is  responsible  for  execution  of 
local  configuration  descriptors.  The  properties  of  this  core  operating 
system  are  described  in  reports  4.2.1  through  4.2.3-  Given  that  UNIX 
supports  message-passing  between  processes,  at  could  be  used  as  the  core 
operating  system.  However,  as  described  in  report  4.2.10  UNIX  needs 
additional  facilities  to  support  multi-user  subsystems.  The  FORTS 
facility  of  Sunshine  [5.6]  and  Zucker  [5.8]  make  it  suitable  as  a  core 
operating  system  onto  which  the  MADEX  distributed  programming 
environment  (DPE)  can  be  adapted. 

The  command  processors  (MIRC,  UMIX,  and  DO),  the  hierarchical  file 
subsystem  (HFSS),  the  link  program  (LINK),  the  network  file  subsystem 
■MF3S),  the  SUBMIT  node,  the  network  configuration  control  ■„ MCC ) ,  and 


Oaer  Terminal  •  User  Terminal 


Alternative  underlying  OS  arohltaoturas 
Physical  Data  Flow 
Logical  Protocol 


SUBSYSTEM 


the  transport  level  (XMS-message  system)  are  all  programs  in 


network-wide  software  configuration.  The  command  processors,  NCC  ar.d 
LINK  programs  have  already  been  discussed,  and  the  HFSS  is  a  prototype 
UNIX  file  system.  The  SUBMIT  node  submits  a  local  configuration 
descriptor  to  the  local  core  operating  system  and  returns  its  completion 
code  to  NCC.  The  NFSSs  communicate  across  the  network  to  control  files 
across  the  network.  Finally,  the  transport  service  (MIMICS)  moves  data 
between  ports  on  separate  machines. 

In  Figure  4  there  is  a  view  of  the  implementation  structure  of  the 
NADEX  core  operating  system.  We  will  refer  to  this  figure  in  describing 
the  adaptability  properties  of  NADEX.  The  outer  ring  ( 1 )  of  the  onion 
consists  of  configurations.  The  NADEX  DPE  resides  at  this  level. 
Therefore,  both  the  NADEX  core  operating  system  and  UNIX  with  PORTS  will 
support  the  NADEX  DPE.  As  shown  in  Figure  3,  a  small  map  between  data 
transfer  streams  and  pipes  in  UNIX  must  be  added  to  SUBMIT  to  adapt  the 
NADEX  DPE  to  UNIX.  (This  map  has  been  programmed  but  not  debugged  due 
to  lack  of  a  good  UNIX  system  available.) 

The  closer  one  gets  to  the  center  of  the  onion,  the  more  machine 
and/or  operating  system  dependent  an  adaptation  of  NADEX  DPE  becomes. 
Since  ail  of  NADEX  DPE  was  written  in  Sequential  Pascal,  it  adapts  to 
message-based  core  operating  systems  very  well.  Only  a  Pascal  compiler 
and  a  SUBMIT  map  are  needed.  This  level  of  effort  is  on  the  order  of 
one  man-month.  Furthermore,  the  NADEX  core  operating  system  (rings  2 
and  3)  are  written  in  Concurrent  Pascal  and,  therefore,  port  cirectiy  to 
any  system  which  supports  hierarchical  Concurrent  Pascal  programs.  Ring 
t  is  the  Concurrent  Pascal  kernel.  It  is  written  in  Sequential  Pasa. 
and  ports  nicely  to  P-code  type  machines  sucn  as  the  Western  Digital 
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Pascal  Microengine. 

Four  feasibility  studies  were  'arried  out  under  this  researcr. 
effort  to  ascertain  the  effort  necessary  to  adapt  the  NADEX  OPE  to 
several  machine  and  operating  system  environments.  It  is  currently 
running  on  a  Perkin-Elmer  (Interdata)  8/32.  The  first  experiment  was  to 
host  it  on  a  UNIX  system.  It  took  about  one  month's  effort  to  code. 
The  second  experiment  involved  studying  the  Concurrent  Pascal  compiler 
to  ascertain  the  effort  to  generate  ?-code  for  the  Western  Digital. 
This  took  about  four  (4)  months  effort  in  its  preliminary  work.  It 
would  take  another  two  months  to  complete  the  task  —  total  of  six  months 
effort.  This  study  is  documented  in  report  4.2.11 . 

The  objective  of  the  third  and  fourth  feasibility  studies  was  to 
assess  the  difficulty  of  integrating  the  facilities  of  the  NADEX  core  OS 
into  existing  core  operating  systems.  The  operating  systems  chosen  were 
Perkin-Elmer ' s  OS-32/MT  and  the  UCSD  Pascal  P-system.  The  approach  was 
to  use  the  kernel  facilities  (ring  4)  of  eacr.  DC  =>:.d  then  integrate 
rings  2  and  3  code  of  NADEX  into  these  operating  systems.  We  programmed 
ring  3  for  both  machines — in  assembly  language  for  the  Perkin-Elmer 
operating  system  and  in  UCSD  Pascal  for  the  other.  In  both  cases,  it 
took  two  month's  effort  each.  Ring  3  seems  to  be  about  twice  as 
complex.  Therefore,  assuming  that  memory  and  other  resources  are  enougr. 
to  hold  NADEX,  3ix  months'  effort  is  a  good  estimate  of  the  total 
porting  effort  per  system.  Df  course,  the  rate  of  generation  and 
understanding  of  this  level  of  coce  is  extremely  sensitive  to  the 
quality  of  the  programmer. 
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2.3  Performance  of  NADEX 

The  study  of  the  performance  of  NADEX  was  carried  out  in  two 
phases.  The  first  phase  was  to  instrument  NADEX  and  record  the 
percentage  of  run-time  that  NADEX  spent  in  each  ring.  The  second  phase 
involved  recoding  rings  3  and  4  and  comparing  the  performance  of  the  new 
and  old  versions.  Table  I  contains  the  percentage  of  time  in  each  ring 
for  a  three-node  configuration  where  the  nodes  only  pass  messages 
between  each  other  and  do  no  real  computation.  The  objective  is  to 
isolate  the  elements  of  the  core  OS  which  can  be  improved  in  speed  and 
get  the  most  improvement  in  overall  performance  of  NADEX. 


}  time  spent 

RING 

4 

29.75 

RING 

3 

15.00 

RING 

2 

40.00 

RING 

1 

15.25 

Table  I 

It  is  clear  from  Table  I  that  the  critical  factors  to  performance 
are  the  kernel  and  the  centralized  buffer  (data  flow)  manager.  In  the 
original  form  of  NADEX,  the  data  (pipeline)  buffer  manager  (called  the 
PBM)  was  written  as  a  decentralized  manager  so  that  contention  for 
buffers  would  not  be  a  bottleneck  if  the  core  CS  were  to  be  run  on  a 
multiprocessor  with  shared  memory.  In  order  to  test  the  overhead  of 
this  structure,  we  recoded  the  PBM  into  a  centralized  version  and  tested 
the  performance  of  both  against  the  performance  of  an  assembler  buffer 
manager  ir.  OS-32,  MT — a  representative  of  current  cay  operating  systems. 
Table  II  gives  the  time  to  transfer  one  message  between  two  nodes  using 
all  tr.ree  modules. 
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Thus,  it  is  clear  that  the  centralized  PBM  is  superior  to  both  other 
methods  and  drastically  improves  the  performance  of  MADEX;  and  it  is 
also  written  in  a  high-level  language. 


Transfer  Time 

Decentralized 

10.0 

milliseconds 

Centralized 

2.3 

milliseconds 

Assembler 

4.0 

milliseconds 

Table  II 
PBM  Performance 

The  next  most  critical  element  of  performance  was  the  kernel  of 
Concurrent  Pascal — ring  1 .  The  only  degradation  in  performance  that  we 
envisioned  was  the  difference  in  performance  of  Pascal  vs.  assembler 
language.  We  chose  to  code  it  in  assembler  as  well.  The  assembler 
kernel  ran  only  5  percent  faster  than  the  kernel  written  in  Pascal. 
This  was  a  surprise.  We  expected  an  improvement  of  at  least  25  percent. 
However,  it  does  give  an  indication  that  a  portable  kernel  written  in 
Pascal  does  not  incur  a  substantial  performance  penalty. 

It  is  interesting  to  note  that  the  code  size  of  the  assembler 
kernel  was  33  percent  smaller  than  the  size  of  the  Pascal  kernel.  Thus, 
recoding  in  assembler  saves  considerable  space  but  does  not  improve 
performance  substantially.  The  size  of  code  of  each  module  in  NADEX  is 
presented  in  Section  6. 

During  the  course  of  this  research  effort,  we  developed  the  concept 
of  a  Concurrent  Prefix.  This  is  similar  to  Per  3rinch  Hansen's  Prefix 
[5.1]  for  Sequential  Pascal  except  that  it  permits  Concurrent  as  well  as 
Sequential  Pascal  programs  to  be  executed  and  have  services  to  the  lower 
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level  Concurrent  Pascal  program — the  OS.  In  this  case,  it  is  NADEX. 
This  provides  a  true  hierarchy  of  virtual  Concurrent  Pascal  machines. 
This  is  illustrated  in  Figure  5.  This  virtual  machine  facility  adds 
significant  levels  of  complexity  to  the  Concurrent  Pascal  kernel.  We 
measured  the  performance  of  both  versions  of  the  kernel.  We  found  that 
the  virtual  CPascal  machine  kernel  ran  42  percent  slower  than  the 
non- virtual  machine  kernel.  Thus,  the  kernel  overhead  to  maintain  the 
hierarchy  of  virtual  machines  is  a  signficant  performance  factor;  and 
only  some  microcode  or  hardware  assist  will  improve  the  performance. 
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3 .0  Future  jforit 

Under  this  research  support,  a  Network  ADaptable  Executive  (NADEX; 
has  been  developed  which  provides  a  distributed  programming  environment. 
This  executive  is  implemented  in  Concurrent  Pascal;  the  results  ox' 
performance  testing  on  NADEX  established  the  viability  of  a  highly 
structured  concurrent  language  for  implementing  operating  systems.  The 
strong  typing  of  Concurrent  Pascal  provides  the  relative  portability. 
Extensions  to  this  work  fall  in  two  areas:  work  to  improve  the  utility 
of  the  NADEX  systems  and  research  into  distributed  computing  for  which 
NADEX  is  an  excellent  testbed.  In  the  area  of  extending  the  utility  of 
NADEX,  a  modified  version  should  be  developed  for  personal  computers. 
NADEX  should  also  be  recoded  into  the  ADA  programming  language  to 
improve  its  portability.  In  the  second  area,  new  distributed 
programming  tools  need  to  be  developed.  NADEX  will  serve  as  an 
excellent  development  environment  and  a  good  performance  test  load. 

In  order  for  an  operating  system  and  its  support  software  to  be 
truly  portable,  it  must  be  written  in  a  language  which  has  wide 
acceptance  as  a  standard;  and  it  must  have  the  support  of  industry, 
academia,  and  the  federal  government  to  provide  compilers  for  many 
machines.  ADA  is  such  a  language.  The  NADEX  distributed  programming 
environment  and  the  NADEX  core  operating  system  would  be  even  more 
portable  if  written  in  ADA.  This  task  is  relatively  straightforward 
because  of  the  closeness  in  philosophy  ar.d  typing  of  ADA  arc  Concurrent 
Pascal.  The  NADEX  distributed  programming  environment  could  be  hosted 
or.  any  machine  for  which  there  is  an  ADA  compiler.  The  NADEX  :cre 
operating  syscem  could  be  used  to  support  this  environment  on  care 
machines  which  permit  access  to  lew- level  devices  from  ADA.  Performance 
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of  these  ADA-based  systems  could  then  be  measured  on  both  high-level 
language  machines  (such  as  the  INTEL  432  (ADA)  machine  and  the  Western 
Digital  ADA  microengine)  and  on  general  register  machines  (such  as  the 
DEC  VAX-1 1/780,  the  Perkin-Elmer  3200  series,  and  the  IBM  370 
architectures)  for  which  compilers  are  now  being  constructed. 

In  order  for  NADEX  to  be  portable  to  smaller  systems  (personal 
computers),  a  version  of  NADEX  should  be  implemented  for  a  Limited 
Capability  Host.  In  this  system  the  small  system  (LCK)  should  be  able 
to  run  local  configurations  as  well  submit  configurations  to  a 
supporting  host  to  distribute  across  a  NADEX-controlled  network.  This 
system  would  provide  the  personal  computer  user  access  to  the  resources 
of  the  network.  Small  machines  such  as  those  running  UCSD  Pascal  or 
TSI-ADA  are  great  program  development  tools  but  sometimes  need  access  to 
larger  machine  resources. 

Further  work  needs  to  be  done  in  the  area  of  run-time  specification 
and  validation  of  inter-program  communications  protocols.  Programs 
(sequential  or  concurrent)  in  software  configurations  communicate  via 
ports  which  have  low-level  properties  such  as  number  of  buffers.  The 
NADEX  core  operating  system  validates  only  the  number  of  buffers  used 
between  programs.  However,  at  the  programmer  level  these  ports  are  data 
streams.  Any  protocol  between  programs  exists  only  in  the  programmer's 
mind.  A  syntax  to  describe  these  inter-program  protocols  is  needed  so 
that  (1)  the  programmer  can  describe  them  in  a  descriptive  manner,  .2} 
the  system  can  compile  these  descriptions,  and  (3)  when  these  programs 
are  combined  together  into  a  software  configuration,  the  ordering  me 
typing  of  messages  exchanged  between  programs  can  be  checked  for 
validity. 
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The  syntax  suggested  by  our  research  is  protocol  expressions  as 
doeunented  in  our  technical  report  [4.2.4].  Extensions  to  include 
predicates  in  protocol  expressions  should  also  be  investigated.  The 
basic  research  to  be  undertaken  would  be  the  syntax,  semantics  ana 
implementation  of  a  Configuration  Description  Language  which 
incorporates  these  inter-program  protocol  expressions.  Properties  cf 
this  language  should  include  hierarchical  encapsulation  (packaging]  and 
documentation  control.  The  obvious  implementation  cf  this  proposed 
system  is  via  a  preprocessor  so  that  it  could  be  modifiea  to  adapt  to 
other  programming  languages  such  as  ADA. 

The  MADEX  distributed  programming  environment  currently  needs 
explicit  commands  from  the  user  in  order  to  distribute  software 
configurations  across  a  network.  This  information  (resource 
availability,  data  program  placement,  and  frequency  of  program/ data  use 
at  each  site]  car.  automatically  be  collected  during  execution  cf  the 
MADEX  environment.  Extensions  to  permit  MADEX  to  collect  and  use  this 
information  would  support  research,  develcpmer.t  ar.d  experimentation  with 
automatic  network-wide  resource  allocation. 

Finally,  MADEX  performance  is  strongly  affected  by  tr.e  transport 
level  message  system)  software  complexity.  Its  pefcrmar.ce  r.eecs  yet  to 
be  tested  on  a  high-speed  local  network.  It  is  hypothesized  tr.at  the 
transport  layer  of  software  is  the  greatest  bottleneck  tc  gcoc 
performance.  Thus,  valuable  research  ir.  performance  cf  costs i cutes 
systems  would  include  development  of  hardware  to  off- leas  trim  transport 
layer  tc  a  microprocessor  which  interacts  wit  r.  a  local  network 
fisre-opti:  cable.  The  performance  of  suer,  a  system  coder  MADEX  ?culs 
then  oe  tested. 
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4.0  At 

4.1 


List  of 


4.1.1  V.  E.  Wallentine,  "Experience  with  Concurrent  Pascal  as  ar. 

Implementation  Language,"  Proceed  i  r.gs  of  the  Conference  on 
Microprocessors  in  POD.  Pingree  Park  Conference  Center,  Colorado, 
August  1979. 

Per  Brinch  Hansen  designed  and  implemented  the  programming  language 
Concurrent  Pascal  [5.1]  on  a  PDP  11/45  at  the  California  Institute  of 
Technology.  In  this  paper,  we  present  the  basic  concepts  in  Concurrent 
Pascal  and  its  relationship  to  Sequential  Pascal.  Concurrent  Pascal  has 
been  used  at  KSU  to  implement  several  large  systems  including  a 
multi-user  operating  system.  We  discuss  the  extensions  to  the  language 
necessary  to  implement  these  systems.  Finally,  we  discuss  the  problems 
involved  in  adapting  Concurrent  Pascal  to  several  machine  environments 
including  microprocessors  with  small  address  spaces. 


4.1.2  V.  E.  Wallentir.e,  "Programming  Issues  in  Distributed  Systems," 
Proceedings  of  the  Network  IPC  Workshop,  Georgia  Institute  of 
Technology,  Atlanta,  Georgia,  November  1973. 

If  we  are  to  be  successful  in  distributing  programs  across  nighly 
distributed  systems,  we  must  provide  the  programmer  of  dynamically 
interconnected  cooperating  processes  a  job  control  language  'software 
configuration  control)  as  easy  to  use  as  Hoare's  communicating 
sequential  processes.  It  seems  that  the  most  promising  direction  is  to 
extend  the  concept  of  the  UNIX  shell  to  automatically  generate  the  mere 
complex  protocols  available  to  the  parent  processes  previous.;.’ 
described.  It  must  then  also  be  extended  to  generate  representations 
of)  distributable  oenf igur3tions  of  communicating  processes.  Wcr<  m 
this  area  is  underway  at  Kansas  State  ‘Jniversity.  The  project  involves 


development  of  a  Network  Adaptable  Executive  ( ,‘iADEX ) .  The  attempt  is  tc 


permit  the  user  to  specify  data  flow  at  the  command  level  and  have  the 
command  interpreter  generate  a  distributable  software  configuration  of 
nodes  connected  by  full  duplex  data  transfer  stream  connections  (UTS 
connections)  to  form  an  undirected  graph.  In  general,  a  node  may  be 
thought  of  as  a  process.  Each  of  the  connections  consists  of  two 
independent  bi-directional  data  transfer  streams.  One  of  these  streams 
uses  small  parameters  while  the  other  uses  a  standard-sized  data  buffer. 
The  data  buffers  carry  along  with  them  size  and  status  indicators 
whereas  the  parameter  buffers  contain  only  a  small  amount  of 
user-supplied  data.  In  this  paper  we  present  a  brief  overview  of  the 
properties  of  software  configurations. 


4.1.3  S’.  J.  Maryanski,  P.  S.  Fisher,  and  V.  E.  Wallentine ,  "Data  Access 
in  Distributed  Data  Base  Management  Systems,"  Journal  of 
Information  and  Management,  Vol.  2,  Number  6,  North-Holland  Publ. 
Co.,  December  1 97 9 - 

Distributed  data  base  systems  have  been  advocated  as  the  solution 
to  a  large  number  of  data  processing  problems  by  increasing  data 
accessibility,  security,  and  throughput  while  reducing  cost  and  resource 
requirements.  Unfortunately,  commercially  available  distributed  data 
base  systems  have  not  yet  appeared.  This  paper  attempts  to  provide  the 
potential  user  or  designer  of  a  distributed  data  base  system  with  an 
understanding  of  the  basic  operational  characteristics  of  such  systems. 
The  emphasis  is  upon  the  mechanism  for  data  access  which  is  an  essential 
component  of  any  data  base  system.  Cur  intention  is  that  the  reader 
gain  an  appreciation  of  the  capabilities  and  complexities  of  distributed 
data  base  management  from  the  explanation  of  the  data  access  mechanism. 


This  paper  first  discusses  the  basic  structure  of  distributed  data 


base  systems  by  detailing  the  functions  of  the  system  components.  Then 
in  parts  three  and  four,  mechanisms  are  presented  for  the  placement  and 
access  of  data  in  a  distributed  data  base  system.  The  fifth  part  deals 
with  the  movement  of  data  among  machines  and  then  the  sixth  section 
briefly  discusses  the  concept  of  multiprocessor  backend  machines.  The 
final  portion  discusses  data  integrity  considerations  in  distributee 
data  bases. 


4.1.4  V.  E.  Wallentine  and  R.  A.  Young,  "NADEX — An  Environment  for 
Distributed  Programming,"  In  preparation  for  the  Journal  of 
Computer  Networks,  June  1981. 

User  access  to  resources  in  a  computer  network  has  typically  taken 
the  form  of  communicating  sequential  processes.  In  such  systems,  a  user 
process  executes  an  application  program;  and  whenever  it  needs  access  to 
a  resource,  it  sends  a  message  to  a  system  (server)  process  on  some 
machine  in  the  network  which  manifests  requested  resource  (for  example, 
a  file  or  device).  The  server  process  then  accesses  the  resource  and 
returns  a  message  to  the  application.  Current  extant  systems  [5.2] 
provide  for  the  distribution  of  multiple  servers  for  file  or  device 
access  to  communicate  to  a  single  application  process.  Medusa  [5.5]  and 
Star  OS  [5.4]  extend  this  facility  to  the  "task  force"  concept  where  the 
tasks  on  a  tightly  coupled  set  of  machines  car.  form  a  general  grapr.  of 
communicating  processes.  In  this  paper,  we  discuss  a  distributee 
programming  environment  called  NADEX  (Network  ADaptabie  Executive)  which 
supports  the  distribution  of  software  configurations  across  loosely 
coupled  networks.  These  software  configurations  are  general  graphs  of 
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programs  where  each  node  communicates  via  ports.  This  extends  the  work 
of  Hoare's  CSP  [5.3]  by  buffering  cn  the  connected  ports  and  by 
permitting  nodes  to  be  concurrent  as  well  as  sequential  programs.  We 
first  present  the  concepts  of  software  configurations  and  their  use.  We 
conclude  with  the  structure  of  the  NADEX  implementation  concepts. 


n.2  KSU  Technical  Reports 

4.2.1  R.  A.  Young  and  V.  E.  wallentine,  "The  NADEX  Core  Operating 
System  Services,  Tech.  Rpt.  KSU-CS-TR-79-1 1 ,  February  1979. 

NADEX  is  an  operating  system  whose  objective  is  to  support  modular 

programming.  This  concept  of  "programming  in  the  small"  which  has  been 

so  successful  in  UNIX  [5.7] — in  the  form  of  pipelines  of  communicating 

sequential  processes — is  extended  to  support  general  graphs  of 

communicating  sequential  graphs  (CSP)  [5-3]  under  NADEX.  These  general 

graphs  are  called  software  configurations  and  consist  of  nodes  which 

communicate  via  Data  Transfer  Streams  (DTSs).  These  DTSs  are 

full-duplex  in  nature  and,  therefore,  support  bi-directional 

communication  between  any  two  nodes  which  they  connect.  Nodes  access 

»  DTSs  via  ports.  These  ports  are  distribution-independent  and, 

therefore,  permit  nodes  of  a  configuration  to  be  distributed  across  a 

computer  network  without  reprogramming. 

NADEX  supports  three  programmer  views — the  single  node  programming 


view,  tne 

data  flew  abstraction,  and  the  overall  sof 

tware 

cc nf igura 

tier* 

structure. 

It  provides  the  compilers  and  PREFI 

X  for 

sequential 

os  n  d 

concurrent 

programs,  the  DT3  operations,  and 

the 

configure 

ticn 

descriptor  for  a  distributable  ecnf iguraticn,  respectively,  for  these 
programmer  views.  It  also  permits  expression  of  these  views  ir.  a  user 
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tailored  system.  Command  processors,  utility  subsystems  (such  as  file 
systems),  and  configuration  description  languages  can  be  specified  by 
the  user.  These  systems  can  be  constructed  upon  NADEX  which  provides 
only  the  essential  elements  of  an  operating  system — interprocess 
communication,  a  representation  for  distributable,  communicating 
processes  (software  configurations),  and  resource  allocation. 

It  is  the  DTS  concept  which  permits  software  configurations  to  be 
distributed  across  a  computer  network  controlled  by  NADEX.  In  this 
document,  we  briefly  describe  the  structure  of  MADEX,  the  basic  concepts 
of  software  configurations,  and  the  services  supplied  by  the  MADEX  Core 
Operating  System  (Core  OS).  We  assume  the  reader  has  knowledge  of 
Sequential  and/or  Concurrent  Pascal  [5.1]  and  a  basic  knowledge  of 
conventional  OS  services  or  a  set  of  desired  OS  services.  Under  this 
assumption,  this  document  contains  sufficient  material  to  enable  the 
reader  to  program  normal  user  programs  as  well  as  his  or  her  own  command 
processors  and  subsystems,  such  as  a  file  system. 


U.2.2  R.  A.  Young  and  V.  E.  Wallentine,  "The  Structure  of  the  MADEX 
Operating  System,"  Tech.  Rpt.  KSU-CS-TR-79-12 ,  November  1979. 

MADEX  is  an  acronym  for  Network  ADaptable  Executive.  MADEX 
supports  the  building  of  software  configurations  which  consist  of  a 
general  graph  of  communicating  nodes.  These  nodes  may  be  sequential  cr 
concurrent  programs  which  access  MADEX  services  through  a  native  PREFIX. 
The  PREFIX  concept  was  originally  defined  by  Per  3rinch  Hansen  as  an 
interface  to  the  SOLO  [5.1]  operating  system.  The  MADEX  Native  PREFIX 
is  the  interface  to  tne  NADEX  Core  OS  and  provides  data  flow 
abstractions  to  the  program  running  in  a  node.  These  operations  permit 
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each  program  (running  in  a  node)  to  exchange  messages  with  other  nodes 
in  a  software  configuration  via  full-duplex  data  transfer  streams. 

In  this  document,  we  first  present  the  concept  of  a  software 
configuration.  We  then  present  the  general  structure  of  NADEX. 
Finally,  we  describe  the  function  of  each  module  of  the  NADEX  Core  OS  as 
it  is  written  in  Concurrent  Pascal  [5.1]. 


4.2.3  A.  Young  and  V.  E.  Wallentine,  "Implementation  of  the  Kernel 
of  Concurrent  Pascal/32,  Tech.  Rpt.  KSU-CS-TR-79-13,  December 
1979. 

Based  on  the  structured  multiprocessing  concepts  in  CPASCAL,  we 
chose  CPASCAL  as  the  implementation  language  for  a  multi-user  operating 
system  called  NADEX — Network  ADaptable  Executive.  In  the  design  of 
NADEX,  CPASCAL  concepts  were  kept  in  mind.  The  dynamic  allocation  of 
resources  (buffers  and  memory)  required  that  the  manager  concept  be 
implemented  as  an  extension  to  CPASCAL.  In  order  to  pass  data  between 
processes  in  an  efficient  manner,  it  was  decided  to  add  records  as 
system  components.  Thus,  a  reduction  in  the  amount  of  data  copying  into 
and  out  of  data  encapsuled  in  classes  is  achieved.  A  side  benefit  of 
records  i3  that  user  access  to  shared  data  need  not  be  constrained  to 
any  particular  data  encapsulation-entry  procedure.  The  mechanism  to 
achieve  the  dynamic  allocation  of  these  system  components  to  processes 
is  controlled  pointers  to  system  components.  These  pointers,  to  classes 
and  records,  are  destructive  assignment  (even  as  parameters)  sc  chat  no 
new  time-dependent  error  possibilities  are  introduced  into  CPASCAL. 

A  second  extension  was  to  introduce  hierarchical  concurrent 
programs.  This  support,  in  contrast  to  the  first  extension  which 
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required  only  compiler  changes,  requires  extensive  kernel  support.  The 
kernel  must  be  aware  of  the  multiple  levels  of  concurrent  programs.  In 
this  document,  we  discuss  the  support  necessary  for  multiple  levels  of 
processes.  A  third  extension  was  facilitated  by  our  implementation  of 
the  kernel.  We  coded  a  portion  of  the  kernel  in  Sequential  Pascal  which 
permits  easy  modification  of  the  functions  within  the  kernel.  Thus,  new 
entry  points  to  the  kernel  could  be  required.  To  solve  this  problem,  we 
introduced  a  kernel  prefix  so  that  no  compiler  changes  are  .necessary 
when  new  functions  are  added  to  or  changed  in  the  kernel. 


4.2.4  K.  L.  Rochat  and  V.  E.  Wallentine,  "A  Software  System  Structuring 
Tool  for  Message-based  Systems,  Tech.  Rpt.  KS'J-CS-TR-cC-Cu , 
August  1980. 

Interest  in  message-based  systems  which  support  software 
configurations  is  increasing.  A  software  configuration  is  a  network  of 
processes  connected  together  by  ports  through  which  they  communicate. 
The  Software  Systems  Structuring  Tool  (S^~)  is  an  attempt  to  integrate 
the  common  aspects  of  message-oased  systems  into  a  software  engineering 
tool  for  the  construction  of  software  conf iguratior.s. 

This  tool  supports  the  typed  interconnection  of  modules  which 
allows  the  verification  of  the  correctness  and  completeness  of 
interconnection,  incremental  construction  of  configurations,  ar.d  an 
implementation-independent  structure  representation.  S:-  uses 
independently  compiled  modules  with  typed  ports  to  construct 
distr ibuticn-ir.de pendent  :or.f iguraticr.3. 

The  anility  tc  provide  enhanced  help  information,  illow  the 
specification  of  parameters  by  position  or  xeywcro,  ar.c  permit  the 
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construction  of  software  configurations  usintt  named  ports  are  features 
which  the  user  will  appreciate.  In  addition,  this  tool  describes  the 
resources  needed  to  execute  each  module. 

This  structuring  system  has  been  implemented  at  Kansas  State 
University  in  conjunction  with  the  NADEX  operating  system. 


4.2.5  R.  Fundis  and  V.  E.  Wallentine,  "Command  Processors  for  Dynamic 
Control  of  Software  Configurations,"  Tech.  Rpt.  XSU-CS-TR-30-02 , 
August  1980. 

Command  language  facilities  for  the  construction  and  execution  of 
software  configurations  (networks  of  communicating  processes)  are  very 
limited  today  because  current  operating  systems  do  not  support  this 
level  of  complexity.  The  Network  ADaptable  Executive  (NADEX)  is  an 
operating  system  which  was  designed  to  support  dynamic  configurations 
(those  configurations  which  are  constructed  at  command  interpretation 
time)  of  cooperating  processes.  These  dynamic  configurations  include 
arbitrary  graphs  which  may  contain  cycles.  Three  command  processors 
have  been  developed  to  demonstrate  the  sufficiency  of  the  NADEX 
facilities  to  support  dynamic  configurations. 

NADEX  facilities,  an  overview  of  the  Job  Control  System,  and  the 
command  processor  configuration  environment  are  presented,  followed  by 
user's  guides  for  the  command  processors.  Each  command  processor  has 
different  responsibilities  and  capabilities  for  handling  conf igurations. 
The  NADEX  static  command  processor  executes  completely  connected 
configurations.  The  UNIX  command  processor  allows  linear  conf igurations 
to  be  constructed  dynamically,  and  the  MIRACLE  command  processor  allows 
the  dynamic  construction  of  arbitrary  configurations.  Cy.ctax  graphs  ar.d 
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sample  user  sessions  are  presented  for  each  command  processor. 


4.2.6  R.  L.  Rochat  and  V.  E.  Wallentine,  "NADEX  Job  Control  system 
Implementation,"  Tech.  Rpt.  KSU  CS-TR-80-05,  July  1930. 

NADEX  is  an  operating  system  whose  objective  is  to  support  modular 
programming.  This  concept  of  "programming  in  the  small"  which  has  beer, 
so  successful  in  UNIX  [5-7]  (in  the  form  of  pipelines  of  communicating 
sequential  processes)  is  extended  to  support  general  graphs  of 
communicating  sequential  programs  under  NADEX.  These  general  graphs  are 
called  software  configurations  and  consist  of  nodes  which  communicate 
via  Data  Transfer  Streams  (DTSs).  These  DTSs  are  full-duplex  in  nature 
and,  therefore,  support  bi-directional  communication  between  any  two 
nodes  which  they  connect.  Nodes  access  DTSs  via  ports.  These  ports  are 
distribution-independent  and,  therefore,  permit  nodes  of  a  configuration 
to  be  distributed  across  a  computer  network  without  reprogramming.  In 
this  paper  the  software  tools  which  support  the  construction  of  software 
configurations  are  described.  These  tools  consist  of  an  interactive 
partial  configuration  descriptor  (PCD)  builder,  a  PCD  decompiler  (text 
formatter),  and  a  linker  of  nodes  (LINK  program).  They  form  the  basis 
for  the  job  control  system  of  NADEX. 


4.2.7  R.  L.  Rochat  and  V.  E.  Wallentine,  "NADEX  Utility  Programs," 
Tech.  Rpt.  KSU-CS-TR-80-06 ,  August  1930. 

In  thi3  paper  two  utility  programs  are  desoriced  which  add 

capabilities  to  NADEX.  These  programs  are  a  hierarchical  file  system 

(HFS  program)  and  a  program  which  allows  a  single  console  node  to  te 


shared  by  several  nodes  of  a  user's  configuration — a  console  multiplexor 
(CM  program).  These  programs  were  developed  for  use  with  the  dynamic 

command  processors  [4.2.5].  The  reader  is  assumed  to  be  acquainted  with 
Sequential  and  Concurrent  Pascal  [5.1],  the  command  processor  functions 
[4.2.5],  and  the  services  of  MADEX  [4.2.1]. 

4.2.8  R.  Sanders,  "A  Graphics  Support  System  for  Programming 

Communicating  Processes,'1  Tech.  Rpt.  KSU-CS-TR-80-01 ,  August 

1980. 

The  complexity  of  many  sophisticated  programming  tasks  requires  a 
methodology  to  simplify  and  filter  information  to  a  manageable  level. 
The  GSS  (Graphics  Support  System)  described  m  this  document  will  draw 
pictures  of  software  configurations.  A  configuration  is  a  cireetec 
graph  containing  one  to  eight  nodes.  Each  node  car.  consist  of  a 
sequential  or  concurrent  program,  be  hierarchical  in  nature,  and  can 
itself  be  a  configuration. 

The  ao3t  important  contribution  of  GSS  is  the  metnod  used  to 

determine  the  complex  relationships  that  exist  between  the  picture 

components. 

Arbitrary  configurations  can  be  decomposed  into  three  distinct 
types  of  objects:  hangers,  pipes,  and  cycles.  The  decomposition  is 

accomplished  by  following  and  analyzing  ail  of  the  node  connections  an: 
constructing  patterns  of  linkage.  The  purpose  cf  cuilsir.g  injects  is  t.. 
define  a  predictable,  repeatable  heuristic  that  will  draw  pictures  :r. 
'he  desired  manner.  The  number  of  r.cces  .r.  an  inject  '.etermir.es  T.e 
shape  of  the  object.  Ar.  object's  shape  is  .sec  *o  select  a  -r—:ef  :r.e>: 
pattern  which  defines  now  the  nodes  will  te  drawn  -“.stive  •  ne 
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another.  Flow  into  and  out  of  nodes  is  studied  to  determine  where  they 
should  be  placed  relative  to  the  picture  and  relative  to  other  nodes 
within  their  parent  object. 

GSS  allows  the  user  to  interact  in  the  drawing  portions  of  a 
picture  or  will  draw  the  picture  without  user  assistance.  GSS  does  not 
build  configurations.  It  is  meant  as  a  documentation  tool  that  assists 
in  the  understanding  of  a  software  configuration. 


4.2.9  3.  E.  Eaton  and  V.  E.  Wallentine,  "Hosting  the  NADEX  Environment 

or.  the  UNIX  Operating  System,"  Tech.  Rpt.  !<SU-CS-TR-d1-C2,  May 

1981. 

Command  language  facilities  for  the  construction  and  execution  of 
software  configurations  1  networks  of  communicating  processes)  are  very 

limited  today  because  current  operating  systems  do  r.ot  support  this 

level  of  complexity.  The  Network  ADaptabie  Executive  (NADEX)  was 
designed  to  support  dynamic  configurations  (those  configurations  which 
are  constructed  at  command  interpretation  time)  of  cooperating 
processes.  These  dynamic  configurations  include  arbitrary  graphs  whic.n 
may  contain  cycles.  The  NADEX  environment  runs  or.  top  of  the  NADEX  core 
operating  system.  The  ooject  of  this  work  is  to  make  the  NADEX 

environment  so  it  will  run  with  the  UNIX  a  trademark  of  3ell 

Laboratories)  operating  system  as  its  core  operating  system. 


I 


4.2.10  V.  2.  Waiientme,  3.  A.  Young,  X.  L.  Poena-  ar.c  Z,  1! 

"NADEX  Implementation  lioces,"  Teen.  Hpt.  EJli-OO-T''- 
Wovemoer  I960. 

In  this  document  v;e  describe  the  implementation  details  c: 
We  discuss  the  oasis  concepts  of  software  configurations,  serfs.;: 


properties , 

subsystems, 

dynamic 

connection 

to  subsystems,  oostrustic 

of  ccnfigur 

utions,  data 

‘-ransfer 

stream  IT  3 

)  napping,  -ir.  i  j  ’  .J  : .  s:  i ^ 

The  level 

of  detail 

pre viiea 

cervei  ^ 

.r/.r'icu  *“  *■  :  r  ■ 

functioning  of  the  WATEX  Core  Operating  Jystem. 


i.2.'  1  !•!.  E.  Listener,,  "Or.  t.ne  Assptati.  sty  of  Multipass  I  cm: 

Variants  of  ’Pascal)  ?— Toce  Machine  .-.ror.ste stores ,  7_ 
r'SU-CS-  .  R-o  l  -  -  s  ,  Way  _•  o  '  . 

Toss  report  is  a  description  of  ar.  effort  to  moo 
code-generation  portion  of  a  multipass  Oor.surrer.t  Pascal 
compiler  so  that  it  will  produce  object  code  for  a  different 
The  original  compiler  generated  ?-Ccue  ' ?as  oal  stuow  machine  .  o : 
virtual  machine.  The  modified  version  •«•;..  -rite  to  :*•  f .  r  t: 
nicrcer.gir.e —  a  misrcoomputer  wr.csc  instruction  _et  ...  si.mi.ar  *  •: 
?-Tcde.  The  similarity  of  instruction  sets  made  :t  ,r 

required  .’edifications  would  oe  straigr.tf orwsrs ,  -r.:  or. at  t:.e 
language  constructs  of  Concurrent  Pascal  mcr.it, :rs,  for  exir.pl 

easily  map  onto  the  mi  oroer.g  one  '  s  architect  ore.  however  , 

; regressed ,  t:.e  r  on  toet -r  al  differences  tec  ace  •-  ii»r.id'i  oant 


. :  nourrent  .-a; 


op  i.  cti  or.  pros  .ess 
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